Moderating and Editing Lists

Much of this section is subjective, based on personal experiences during nearly two decades of list ownership, and may not necessarily match your own philosophy of "the way things ought to be." The following sections are offered as one way to run a list, and the author does not mean to assert that the one way offered is the only way. As we seem to say so often, "your mileage may vary."

One of the most important things you can do as a list owner is make it clear from the outset what policies are in place and will be enforced if it becomes necessary. Due to a potential for controversy, for instance, some lists may require a formal "list charter" by which all subscribers must agree to abide before they are allowed to subscribe. Other lists may be able to get by with a simple welcome file (see below) that spells out basic netiquette, polices on "flaming" and commercial posts, and anything else that seems appropriate (such as how to get in touch with the list owner in an emergency, where the list archives are located, etc.).

It is particularly important on open subscription lists that you make a concerted effort to remind your subscribers on a regular basis of the policies you have set for your list, as well as any other information they need in order to make best use of your list. If you have a great deal of subscriber turnover, it may be necessary to do this every few weeks. You may decide to put together a quarterly or semi-yearly post for more stable lists. Ensure that the subject line is indicative of what the administrative posting is so that there is no question as to whether or not you posted it (even if subscribers don't read it). (Note that you can use the PROBE1 mail template form and automatic address probing to do this.)

By default, the list owner becomes a moderator of sorts, even if the list in question is neither edited nor officially moderated. This means that, as a list owner, you must be prepared to maintain order if it becomes necessary. At the same time, you must moderate yourself so that you do not alienate users and cause your list and/or host institution to suffer as a result. Thankfully, mailing lists have generally enjoyed relative peace and quiet over the years in comparison to newsgroups, but mailing lists have unique problems of their own.

Lists dedicated to controversial subjects are more likely to become arenas for "flame wars" between subscribers with hard-held and differing opinions than those dedicated to the discussion of popular software packages, but this does not mean that the latter are immune any more than it means that the former are constantly plagued by flames. The example set by you as list owner and as a participating subscriber to the list is perhaps the most important factor in whether or not your list becomes a site known for strife and controversy. In other words, if you appear not to care about whether or not discussion is on topic and/or civilized, no one else will, either. Yet if you become a policeman – the other end of the spectrum – no one will want to subscribe or participate for fear of your wrath. Either way, your list is unlikely to last very long.

The middle ground is, as in most things, the place to be when administering a list. Some call this "firm but fair," letting things go pretty much as they will but stepping in with a wry or gently chiding remark from time to time when exchanges get heated. And they will! Software discussion lists are particularly bad about this when new subscribers ask "frequently-asked questions" (FAQs) and veteran subscribers respond in exasperated fashion with "RTFM!" (Read The Fine Manual) and similar nasty retorts. Good list owner practice at this point is likely to be a good-natured reminder from you that flames belong in private mail, pointing out that new subscribers have no way of knowing that the particular questions they ask have been asked (and answered!) “n” random times before, and possibly adding a link to the list's archives (if they are available on the web) or instruction on how to use the SEARCH command or the web-based archive search feature to look for answers before asking.

Finally, if your mailing list has an international audience, you must be careful to account for language problems and cultural differences. You will need to decide which languages are allowed or not allowed on the list; this should be mentioned shortly in the list abstract or welcome message. Unless the list is specific to one country or is explicitly for discussion in a specific language, the official language will probably be English. As your list grows, some subscribers may object to this decision, arguing that people who have trouble expressing themselves in English should be allowed to use their own language, with the understanding that many people will be unable to understand what they are saying. As the list owner, it will be your call. Usually, the best compromise is to start a separate list for discussions in the new language. However, you must be careful in wording your decision. In multi-lingual cultures, it is usually considered a courtesy to use the other person’s language. It is certainly considered rude for people to demand that everyone else should speak their language. Thus, if your native language is English, you will be in a delicate position. To avoid a flame war, you will want to make sure that your decision does not come out as a unilateral demand. Politely suggesting a separate list, and tolerating an occasional non-English posting when the poster genuinely cannot speak English, is often the best course of action.

Another possible source of flame wars is unintended rudeness. It is easy to forget that non native speakers are making an effort every time they post something to the list. People will make mistakes, sometimes appearing rude when they did not mean to, simply because they used the wrong word. Another cause of apparent rudeness is cultural difference. Things which are perfectly normal in one culture can be insulting in another. For instance, ad hominem attacks are perfectly acceptable in some countries. Conversely, referring to other people by their first name ("As Peter said in his last message,...") can be downright insulting in some cultures, where anything short of the full title is at best condescending. But, of course, in other countries the use of the full title is considered sarcastic... There is no middle ground here, because there are too many conflicting cultures and too many languages. The only way to successful cross-cultural communication is through the tolerance of other people’s cultural habits, in return for their tolerance of yours.

Edited lists are generally used for the purpose of "full moderation" or for refereed electronic journals or the like, for which random postings from subscribers and/or non-subscribers may not be welcome for general distribution. This places the list owner and any editors in the position of being full-time monitors of what is and is not allowed to go through to the list.

A word of warning to potential list editors: Rules on the Internet are not set in stone. Some people will insist on their right to post without what they will term "censorship" by the list editor. Some will become upset to the point of threatening to report you to your local computing center administrators for abridging their freedom of speech, or (in the U.S.) even threatening to sue you/your institution for an abridgment of their First Amendment rights. It is therefore important to you that you keep a "paper trail" of such complaints in the event that threats become reality and you are asked about them. This common practice in the business world should be common practice in list ownership as well.

Freedom of speech and copyright issues on the Internet have not yet been tested in the courts as of this writing. These are both areas in which list editors and list owners must tread carefully. Always document any problems you may have in these areas.

The "Moderator=" keyword and moderation "load-sharing" are not available in LISTSERV Lite.

Note: L-Soft currently recommends that edited lists be coded with the ",Confirm" parameter to the "Send=" keyword, in other words:

* Send= Editor,Confirm
– or –
* Send= Editor,Hold,Confirm

This will help prevent malicious users from forging mail from an editor address in order to get around your moderation settings, by telling LISTSERV to require an "OK" confirmation whenever it receives a posting from an editor address. The "OK" request goes to the editor address, so the forger is stymied.

Some vacation programs and broken mailers have recently been "reflecting" mail back to lists in such a way that the mail appears to be coming from the editor’s address (and the mail therefore gets through). Setting the ",Confirm" option will stop this phenomenon as well.

When confirmation is required for Editor postings, please note that the confirmation request always goes to the Editor who posted, even if you have moderation "load-sharing" configured as noted below. Moderation "load-sharing" applies to postings from general users only.

Should you decide that an edited list is the way to go for your particular situation, you need only add the following lines to your list header file:

where "userid@some.host.edu" should be replaced with the network address of the person who will be handling submissions to your list.

There can be multiple editors as well (and multiple Editor= lines, if desirable), and they do not have to be list owners:

Normally, LISTSERV forwards submissions only to the first editor defined by the "Editor=" keyword. In the case above, all submissions would go to the primary list owner.

Note: The first editor CANNOT be an access-level; e.g., you cannot use the notation "Editor= Owner" to define the first editor. LISTSERV requires that the primary editor of a list must be the e-mail address of a real person.

This does not apply to second and subsequent editors. For instance, in order to allow subscribers to post directly but have non-subscriber posts sent to an editor for approval, you can code something like:

* Send= Editor
* Editor= alex@reges.org,(MYLIST-L)

On a high-volume list, LISTSERV allows you to share the editing load via the "Moderator=" keyword. By default, this keyword is set to the same value as the first editor defined by "Editor=". When you define more network addresses with the "Moderator=" keyword, LISTSERV sends submissions to each moderator in sequence. The difference between the "Editor=" and "Moderator=" keywords lies in the fact that while any editor can post directly to the list, only moderators receive the forwarded submissions from non-editors.

Here is an example of a list with both Editor= and Moderator= keywords defined:

This list will "load-share" the editing duties between Kent and Joe. Tony is able to post directly to the list, but will not receive forwarded subscriber posts for editing.

Note: Whereas an Editor is not required to be a Moderator, a Moderator should always be listed as an Editor. LISTSERV currently compares the contents of the "Editor=" and "Moderator=" keywords and consolidates the two sets of parameters if necessary, but coding lists this way is not considered good practice and the "compare/consolidate" feature may be removed in a future upgrade.

If the parameter "All" is coded before any moderator addresses, LISTSERV will send copies of all postings to all moderators, any of whom may approve the message. An example of this would be

* Moderator= All,kent@net.police.net,joe@foo.bar.edu

Assuming "Send= Editor, Hold", once a message is approved by one of the moderators, any other moderator attempting to approve the same message will be told that an identical message has already been posted to the list.

If "Send= Editor" (e.g., without "Hold"), then if a note is appended or prepended to the edited post, or if the body of the post itself is edited (that is to say, if the body of the approved message is changed), duplicates are possible. Thus, it is important that the moderators of any list set up this way pay close attention to whether or not the posting has already been approved by another moderator.

By default, LISTSERV forwards subscriber contributions to the Moderator/Editor with the following paragraph prepended to the message body:

This message was originally submitted by JOE@FOO.BAR.COM to the ACCESS-L list at PEACH.EASE.LSOFT.COM. If you simply forward it back to the list, using a mail command that generates "Resent-" fields (ask your local user support or consult the documentation of your mail program if in doubt), it will be distributed and the explanations you are now reading will be removed automatically. If on the other hand you edit the contributions you receive into a digest, you will have to remove this paragraph manually. Finally, you should be able to contact the author of this message by using the normal "reply" function of your mail program. ------------ Message requiring your approval (25 lines) ------------ [message body]

If you leave this paragraph prepended to the message, LISTSERV will strip it off when it processes the message and to all intents and purposes the message will appear to have come directly from the original sender. Warning: If your mail program or client does not generate "Resent-" fields, the forwarded postings will appear to be coming from you rather than from the original sender. See Section 6.6 Message Approval with Send= Editor,Hold for an alternative if your mail program does not generate these fields.

Note: If you leave the editor-header paragraph on the message, make sure that your mail client or mail server does not insert quoting characters (e.g., ">") at the beginning of all of the lines in the message when you use the forwarding function of your mail program. If this happens then the editor-header will not be stripped from the message.

When you are ready to edit and/or submit the contribution to the list, simply use the "Forward" function of your mail client. You can make any changes you feel are appropriate to the message body, but be sure to read Sections 6.2 The Role of the List Owner as Moderator and 6.3 The Role of the List Owner as Editor before deciding.

LISTSERV includes an optional mechanism allowing you to simply "ok" messages which are then posted with all the correct headers. This option is targeted mainly at list moderators who just approve/reject messages, as opposed to people who actually edit the content of messages. The option is also a good choice if you have a mail client that does not insert "Resent-" header lines into forwarded mail.

To activate this feature, code your list "Send= Editor,Hold" and be sure that you have defined at least one editor who will be in charge of approving the messages. A copy of the message on "hold" is sent to the editor with minimal instructions (in order to avoid adding a long message before the text needing approval each time).

To approve a message forwarded to you with "Send= Editor,Hold", simply reply to the approval request and type "OK" as the body of your reply. LISTSERV will normally pick up the confirmation request number from the subject line. If there is a problem, LISTSERV may ask you to resend the approval confirmation along with the number. For instance,

If the message has been in the spool longer than the time-out period (LISTSERV holds these jobs for a minimum of 7 days), you will receive notification that the confirmation number does not match any queued job. If you need to increase the time-out period, you can set a value for the "Confirm-Delay=" list header keyword that is greater than 168h, but please read the section on "Confirm-Delay=" in the List Keyword Reference document before doing so.

If you do not want the message to be forwarded on to the list, you need not do anything. The message will expire automatically at the end of the time-out period and will be deleted from the queue.

List topics are not available in LISTSERV Lite.

List topics provide powerful "sub-list" capabilities to a list. When properly set up and used, topics give subscribers the ability to receive list postings in a selective manner, based on the beginning of the "Subject:" line of the mail header. It is important to note the following points about topics:

• Topics are best employed on moderated lists. This makes it possible to review the "Subject:" header line to make sure that it conforms to one or more of the topics defined for the list before you forward the post to the list. Not only does this help catch simple errors (such as misspellings of the topic), but it also allows the moderator to add a topic into the subject line if one is not already there.

• If you employ topics on unmoderated lists, your subscribers must be well-educated in their use. Otherwise, there is no point in using them. Messages that do not conform to a specified topic are lumped into the reserved topic "Other" and are distributed only to subscribers who have explicitly defined "Other" as a topic they wish to receive. Therefore, some subscribers will receive the message and some won't, and it is problematic as to whether the message will actually reach the entire audience for which it is intended.

• It is important to note that topics are active only when the subscriber's subscription is set to MAIL. All messages posted to the list, regardless of topic, are included in the digest and/or index for the list (if available) because the same digest/index is prepared and sent to all the digest/index subscribers. Similarly, all messages posted to the list are archived in the list's notebook logs (if available), making it possible for subscribers to retrieve postings in topics they are not set to receive normally.

The basic keyword syntax for defining list topics in the list header file is:

And the basic syntax used to set topics for users once they have been defined is:

where xxx, yyy, and zzz can be:

• Updates to the list of topics the subscriber currently receives. A plus sign indicates a topic that should be added, a minus sign requests the removal of a topic. For instance, "SET XYZ-L TOPICS: +NEWS -BENCH" adds news and removes benchmarks. If a topic name is given without a + or - sign, + is assumed; "SET XYZ-L TOPICS: +NEWS BENCH" adds news and benchmarks. The first topic name must have the plus sign to show that this is an addition, and not a replacement.

The colon after the keyword TOPICS: is optional, and TOPICS= is also accepted. The subscriber should not forget to include the special OTHER topic if you want to receive general discussions which were not labeled properly. On the other hand, if the subscriber only wants to receive properly labeled messages it should not be included. ALL does include OTHER.

With the "Default-Topics=" keyword, you can also set default topics for users that will be effective as soon as they subscribe to the list. For instance,

would set the new user to receive topics NEWS, BENCHmarks, and any messages that are incorrectly labeled.

You may get a listing of topics with the number of subscribers who have them set by issuing the command

(if you do not specify Short then the topic listing follows the list of subscribers in the review output). The following is a sample output (assuming you actually have topics enabled; if topics are not enabled then the TOPics option is ignored):

* Topic Subscribers
* ----- -----------
* Apps 1,411
* Backup 1,330
* Beta 951
* Bugs 1,416
* Comm 1,395
* Desktop 1,407
* Hardware 1,401
* Install 1,373
* Internet 1,002
* Network 1,399
* Wish 1,336
*
* "Other" topic 1,294
* Digest/index subscribers 1,384

See the List Keyword Reference document under the Topics= keyword for more information on setting up and using list topics.

When a user subscribes and signs off of a list, LISTSERV looks for list owner-supplied files called listname.WELCOME and listname.FAREWELL, respectively. If found, it sends the user a copy of the appropriate file in addition to its own administrative message. The WELCOME and FAREWELL files allow the list owner to send a more personal message to the user that can help set the tone for how the list is used. The WELCOME file may contain information about the list charter and netiquette rules, or be simply a message welcoming the user to the list. The FAREWELL file can be used to gather feedback about how the list is serving users.

The procedure differs slightly on VM systems, but the following will work for unix, VMS and Windows systems:

at the top of the message (or directly following the "Subject:" line if one is configured). The value "ISO-8859-7" is used here as an example only and should be replaced with the appropriate character set descriptor. If the file does not contain any non-7-bit ASCII characters, this line will be ignored.

The variation for VM systems is that the LISTSERV maintainer will have to create a fileid for the file before you can PUT it on the server. Contact the LISTSERV maintainer before trying to store your WELCOME and/or FAREWELL files.

Here is the format of a very simple WELCOME file. (Note that the FAREWELL file is created and stored in an identical manner.)

PUT SONGTALK WELCOME PW=XXXXXXXX Subject: Welcome to Songtalk! Welcome to Songtalk, the list for Songwriters talking about their work. Your list owner is Susan Lowell (susan@example.com).

The WELCOME file should contain information geared toward orienting the new subscriber to several areas. The outline of a suggested WELCOME file follows:

Naturally, list owners should write WELCOME files based on their own experience of what is needed. A WELCOME file should not be static – review it once in a while to ensure that it continues to meet the needs of new subscribers.

The following FAREWELL file was anciently used on the ACCESS-L list on PEACH.EASE.LSOFT.COM, and was intended as a tool to get feedback from users. When it was in use ACCESS-L's list owner typically received 3-5 responses to this message each week.

Subject: Your ACCESS-L Signoff Request I'm sorry to see that you're leaving ACCESS-L. If there is anything you believe ACCESS-L should have offered but didn't, or there are any other suggestions you may have for the list, please feel free to write directly to me. Sincerely, Nathan Brindle <nathan@indycms.iupui.edu> ACCESS-L List Owner

It is possible to modify LISTSERV's default mail template so that only one message is sent to users when they subscribe and unsubscribe, rather than an administrative message from LISTSERV and a WELCOME or FAREWELL file from the list owner. See Section 9 Creating and Editing Mail and Web Templates for the details on modifying the default mail templates.

However, it is likely that the average list owner will prefer to use the WELCOME and FAREWELL files over changing the more-complicated templates. Thus both avenues are provided, and may be used depending on the list owner's level of comfort.

Like so many other things, network users tend to expend a great deal of virtual gunpowder about the subject of etiquette on the network (otherwise known as netiquette). Part of the culture of the network is built on the fact that an individual user can put forward any face he or she cares to present. Thus, over time, the network has evolved various sets of rules that attempt to govern conduct. To avoid taking up a great deal of space arguing the merits of differing systems of netiquette, the following general pointers that should be accepted by most users are offered for the convenience of the list owner.

The Internet is international, and while English is generally accepted as the common language of the network, list owners and list subscribers cannot afford to take the position that everyone on the Internet understands English well. In a medium that is invariably connected to language, special understanding is required to deal with questions or statements from people for whom English is not the primary tongue. Often today (at least in the US) a person's first sustained interaction with others on an international basis is via the Internet. It is imperative that this interaction be on the highest level of cordiality and respect from the outset in order for all concerned to benefit.

Additionally, care should be taken when using local idiom and slang. A common word or phrase used by Americans in everyday speech, for instance, might be taken as profanity or insult by those in other English-speaking countries, and may not be understood at all by non-native speakers of English. When a list has a high international readership, it is probably best to avoid non-standard English so as to provide the clearest and least-objectionable exchange of ideas.

If someone on a mailing list has sent a private message to you (i.e., not to the list at large) and you have lost that person's address but want to respond, do not post private mail to the list. The REVIEW command will give you a copy of the list membership that you can search for the person's address. If this approach does not work, contact the local postmaster or the list owner for help.

Flames (insults) belong in private mail, if they belong in mail at all. Discussions will often result in disagreements. Rebuttals to another person's opinions or beliefs should always be made in a rational, logical and mature manner, whether they are made publicly or privately. What is a flame can range from the obvious (ranting and raving, abusive comments, etc.) to the not-so-obvious (comments about how many "newbies" seem to be on the list these days, "RTFM!" exhortations, etc.).

Subscribers should refrain from abusive or derogatory language that might be considered questionable by even the most liberal and open-minded of networkers. If you wouldn't say it in front of your mother, don't say it in electronic mail.

Most of these are contrary to appropriate use policies governing the use of the poster's Internet access provider. Not only that, they are annoying and (in the case of chain letters) often illegal. See Section 6.10 on the subject of "spamming" for more details.

Self-explanatory. It is rarely possible to catalog all forms of anti-social network behavior. Be sure that you as a list owner cover as many bases as you think necessary when promulgating a code of netiquette for your list. Then, be sure to adhere to it yourself.

"Spamming" is a network term invented to describe the act of cross-posting the same message to as many newsgroups and/or mailing lists as possible, whether or not the message is germane to the stated topic of the newsgroups or mailing lists that are being targeted. A "spam" is defined therefore as either (1) a specific act of spamming, such as the original so-called "Green Card Spam", or (2) the message that actually comes to your list as a result of someone initiating a specific act of spamming ("The message you just saw was a spam, and it should be ignored"). Spams are fairly easy to recognize at a quick glance; they often have "To:" fields directed to large numbers of lists, usually in alphabetical order.

If a spam gets through to your list, it will probably engender sarcastic replies (often with the spam quoted in its entirety) – and if your list is coded "Reply-To= List", they will likely come back to the list. It is therefore imperative that you make subscribers aware that when a spam occurs:

Perhaps the best policy an individual subscriber can adopt toward spammers is simply to ignore them and allow list owners and newsgroup moderators to take care of the problem. If this does not work and subscribers send their complaints to the list anyway, it might be a good idea to moderate the list for a few days until the furor dies down.

LISTSERV attempts to detect "spams" using a variety of proprietary methods. When LISTSERV decides that a message is a spam, it locks out the user for 48 hours, worldwide in the case of registered LISTSERV networked servers. While locked the user is still able to use LISTSERV normally and to post to mailing lists, but all messages will be forwarded to the list owners for human verification. The user is informed that this has happened but is not informed of which lists caught the message and which didn't, denying him any idea how successful he has been.

L-Soft will not document how LISTSERV decides a message is a spam because the point has been reached where a number of authors are writing and selling books detailing how to avoid such precautions. If L-Soft were to document its methods, the next editions of these books would simply include updated instructions on how to bypass them.

If you are interested in a discussion of the phenomenon of SPAM, you can join the SPAM-L mailing list on LISTSERV@PEACH.EASE.LSOFT.COM.

As a list owner, it is important that you take into consideration any appropriate use policies that might apply to your list. For instance, if your list is hosted by an educational site that has a policy restricting mail with commercial content from being sent out by its users, your list will technically be in violation of that policy if it distributes mail from users advertising commercial services. You would be well advised to request a copy of the appropriate use policy (if any) from your host site and make sure that your subscribers are aware of it by including pertinent sections in your WELCOME file and/or your administrative postings.